Date: Fri, 8 Apr 94 04:30:01 PDT 

From: Packet-Radio Mailing List and Newsgroup <packet-radio@ucsd.edu> 
Errors-To: Packet-Radio-Errors@UCSD.Edu 

Reply-To: Packet-Radio@UCSD.Edu 

Precedence: Bulk 

Subject: Packet-Radio Digest V94 431 

To: packet-radio 


Packet-Radio Digest Fri, 8 Apr 94 Volume 94 : Issue 31 


Today's Topics: 
BBS-to-Internet address transformations 


Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu> 
Send subscription requests to: <Packet-Radio-REQUEST@UCSD.Edu> 
Problems you can't solve otherwise to brian@ucsd.edu. 


Archives of past issues of the Packet-Radio Digest are available 
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio". 


We trust that readers are intelligent enough to realize that all text 
herein consists of personal comments and does not represent the official 
policies or positions of any party. Your mileage may vary. So there. 


Date: 7 Apr 1994 22:43:55 -0700 

From: network.ucsd.edu!not-for-mail@network.ucsd.edu 
Subject: BBS-to-Internet address transformations 

To: packet-radio@ucsd.edu 


[Some of you (well, Hank, anyway) seem to have missed this proposal the first 
time around. Here it is again. ] 


Any hambbs-to-internet gateway which forwards mail will be required to 


1) be fully registered (both A and MX records) with 
the AMPR.ORG domain server. 


2) be able to utilize MX records for mail exchange on the 
internet. 


3) be capable of accomodating a routing table large enough to 
handle all the ham packet BBSs that will be routing to the 
internet through it, and automatically update that table. 


4) be able to generate MX records as required and submit them to 
the central ampr.org database maintenance robot, either 


automatically or by hand. 
The procedure is: 


When mail arrives from an AX.25 bbs at a ham-to-internet gateway 
system, the gateway 


1) updates its routing table for that BBS to reflect the routing 
hints contained in the return address. 
E.g., mail arriving at the WB6KDT gateway 


FROM WB6XYZ@WBECYT.#SOCA.CA.USA.NOAM 
generates a routing table entry of 


WB6CYT d#SOCA.CA.USA.NOAM 
(or whatever the gateway needs to know to reach the bbs via packet) 


2) the bbs from line is rewrittenx* as 
From: WB6XYZ@WB6CYT .AMPR.ORG 


and the mail is injected into the internet 


3) An MX record for WB6CYT.AMPR.ORG is established (if it does 
not already exist)**x, pointing to the gateway system (in this 
example, WB6KDT.AMPR.ORG) with a preference value equal to the 
number of stations the message took to make it to the gateway 
from the bbs where it originated. 


Yes, it's a bit elaborate. But it's RIGHT. It's clearly the way it 
ought to be done. Let's do it. 
- Brian 


x Yes, rewriting addresses is supposed to be a sin. It's unavoidable 
when you change addressing methods between networks, so in this case 
we have to do it. I don't like that either but there's no choice. 


xx Yes, there's a timing problem here if a reply message is sent 
before the nameserver gets updated and propagated. It's a one-time 
problem, though, and could be solved by pre-registration. After all, 
how many BBSs are there near each gateway system? 
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